Computer operating systems commonly incorporate a feature to communicate system and application information to and from a variety of devices from multiple manufacturers. The growth of the computer industry has engendered a large number of companies who provide both hardware and software peripheral products for the market. In all of these cases, the operating system manufacturer has to ensure the compatibility and the exchange of data within and between the computers on which such hardware and software are installed. To ensure that the multitude of application programs that are executed on a computer system are able to effectively communicate with peripheral devices, the operating system designers have developed interfaces that allow device-independent access. Two such interfaces are a graphics device interface (GDI) and a Generic Printer Definition Language (GPD), both of which were developed specifically to deal with printer devices.
The GDI affects the output data from the application programs by invoking functions which allow access to printing devices in a device-independent manner. GDI provides a uniform interface to the application programs and the output peripheral devices to which the programs send data. Not withstanding this uniform interface, GDI is unable to produce actual printer control commands which are capable of driving each of the multiple models of printer devices available on the market. As such, each individual printer required its own individual printer driver that could implement the various control functions of the respective printers, based upon the standardized output from the GDI. These standard functions included initialization, information, output, attribute, mode and escape sequences. While each of these monolithic drivers provided the necessary interface for each printer, they were typically very large in size. The need for such extensive drivers impacted not only the printer manufacturer and the operating system vendor, but also the individual computer system into which such drivers would be installed. Specifically, the space requirement and resource utilization on a system become unwieldy especially when more than one printer needs to be supported. In addition, the development and coding of these drivers is cumbersome at best. To overcome the problems related to GDI, a Graphical User Interface (GUI) tool was developed to aid in writing these drivers. This tool included a Generic Printer Characterization (GPC) which was intended to provide an application independent of describing the total functionality and capabilities of one or more printers supplied by a printer Original Equipment Manufacturer (OEM). GPC has limited capability to describe printer devices and limited extensibility for printer features. This led to the development of a flexible modular architecture of syntax and semantics to be used in printer definitions known as GPD. This definitional language provides better support for more varieties of printers, and improves the output quality, ease of use and performance without the necessity for redesign.
GPD is a text-based printer description file format for creating mini-drivers that run with a single universal driver. Typically there is one GPD file for each printer model with the ability for different printers to also share a GPD file. A GPD file describes all the features on a printer including how to display and invoke these features. A GPD file also contains printer-specific commands and attributes that enable the Universal Driver to generate the correct printer-ready output data.
Although GPD provides support for generic features, custom help, installable options and various types of constraints, it is limited in the fact that it is only directed to printer devices. The support provided in GPD for value dependency allows developers to describe any kind of dependency between printer commands and or attributes. This support, combined with the command parameter specification scheme while useful, are also some of the constraints on wide scale applicability of the language. The Parser for GPD parses data into a single binary format, as such, the Universal Driver need not worry about different binary formats as was the case with GPC revisions and monolithic drivers. The GPD Parser none the less has other drawbacks. For instance, the static (non-extensible) set of Attribute:Value pairs and predefined collections of these pairs (Constructs) that can be used to describe the characteristics of printer devices, require that as new features are added to the printer, new Attribute: Value pairs or Constructs need to be defined and added to the GPD language thereby necessitating changes to the GPD Parser at a programmatic level.
The task of describing the semantics of GPD constructs is complicated by the fact the semantic content is dependent on the context in which the construct occurs. For example an *Options construct that appears within a PaperSize *Feature has different members than an *Options construct that appears within a Resolution *Feature. Indeed, an *Option describing Custom papers is different from an *Option describing system-defined papers and even an *Option describing Letter size paper is different from an *Option describing Legal size paper. This makes a description using a typical Extensible Markup Language (XML) schema impossible. Although XML is a meta-markup language that provides a format for describing structured data by encoding content, semantics and schemata for a wide variety of cases, XML lacks the ability and functionality that allows descriptions to inherit the properties and characteristics of a base description. A description using a template containing many nested Switch/Case dependencies is awkward at best. A way to define relationships between templates using the object oriented concept of Inheritance would yield a simpler and more robust language feature. While this concept is available in object oriented programming languages such as C++, the application of inheritance in these languages is directed and applicable to source code and memory space. In fact, the purpose and use of inheritance in these environments is as a means to polymorphism (the ability to view two or more similar objects through common interface, thus eliminating the need to differentiate between the objects), and reusability of code.
While the concept of easily describing and categorizing groups of data as defined by XML has multiple advantages, it lacks the robustness, ability and structure provided by the notion of inheritance. Multiple individuals cannot easily enhance or grow an XML descriptive or definitional grouping without modifying the underlying grouping, thus creating compatibility problems with any applications or programs that utilized the original data grouping. Similarly, the ability to utilize inheritance within Object Oriented Programs (OOP) such as C++ lacks the ease of use provided by XML. Individuals are forced to defined subjects as combinations of code and memory segments in OOP, which obfuscates the desired simplicity in defining or describing subjects.
Accordingly, there exists a need to avoid the overhead needed to continuously update descriptive languages and Parsers while also providing flexibility in the description or definition of subject data. A meta-language which permits third parties to add any Attribute:Value pairs or Constructs that they desire and to describe the new Attributes using Templates without the requirement of modifying the language or the Parser is needed. The use of Template Inheritance, ensures that extended data formats remain compatible with any applications and utilities that are designed to work with an original data schema. Furthermore, the use of a generic meta-language that is both powerful and easy to use, provides the ability to implement descriptions and definitions for purposes beyond printer description or characterization language.